first

Daisy Diff compare report. Click on the changed parts for a detailed description. Use the left and right arrow keys to walk through the modifications.

last

DRAFT Protection Profile for General-Purpose Computing Platforms DRAFT

This page is best viewed with JavaScript enabled!

Version: 2.0.9
20222025-01-1013
National Information Assurance Partnership

Revision History

Contents

1 Introduction

1.1 Overview

• NIAP, BIOS Update for PC Client Devices protection Profile, Version 1.0, 12 Feb 2013
• NIST SP 800-147 BIOS Protection Guidelines, April 2011
• NIST SP 800-147B BIOS Protection Guidelines for Servers, August 2014
• NIST SP 800-193 Platform Firmware Resiliency Guidelines

• NIST SP 800-155 (Draft) BIOS Integrity Measurement Guidelines (Draft), December 2011
• NIST SP 1800-34 (Draft) Validating the Integrity of Computing Devices (Preliminary Draft), 2021
• Trusted Computing Group, TCG PC Client Platform Firmware Integrity Measurement Version 1.0 Revision Specification 43 Family 2.0, May 7, 2021
• IEEE Std 802.1AR-2018, Secure Device Identity

1.3 TOE Overview

1.3.1 TOE Boundary

Figure 1: High-Level Architecture of a Generic Platform

1.3.2 TOE Operational Environment

1.4 Use Cases

• a TOE that meets [USE CASE 2] Server-Class Platform, Enhanced also meets [USE CASE 1] Server-Class Platform, Basic
• a TOE that meets [USE CASE 5] CSfC EUD also meets [USE CASE 4] Portable Clients (laptops, tablets), Enhanced and [USE CASE 3] Portable Clients (laptops, tablets), Basic, and
• a TOE that meets [USE CASE 6] Tactical EUD also meets [USE CASE 4] Portable Clients (laptops, tablets), Enhanced and [USE CASE 3] Portable Clients (laptops, tablets), Basic.

[USE CASE 1] Server-Class Platform, Basic

This use case encompasses server-class hardware in a data center. There are no additional physical protections required because the platform is assumed to be protected by the operational environment as indicated by A.PHYSICAL_PROTECTION. The platform is administered through a management controller that accesses the MC through a console or remotely.

This use case adds audit requirements and Administrator authentication requirements to the base mandatory requirements.

For changes to included SFRs, selections, and assignments required for this use case, see G.1 Server-Class Platform, Basic.

[USE CASE 2] Server-Class Platform, Enhanced

This use case adds physical protections to the base requirements for server-class hardware. Additional physical protections are required because the platform us assumed to be minimally protected by the by the operational environment. This use case can also be invoked for servers in data centers where there are enhanced security requirements.

This use case adds requirements for audit, physical protections, and Administrator authentication to the base mandatory SFRs. It removes the assumption that the TOE is physically protected by the OE.

For changes to included SFRs, selections, and assignments required for this use case, see G.2 Server-Class Platform, Enhanced.

[USE CASE 3] Portable Clients (laptops, tablets), Basic

This use case defines the base requirements for portable clients.

This use case adds no requirements to the base mandatory SFRs.

[USE CASE 4] Portable Clients (laptops, tablets), Enhanced

This use case adds physical protections to the base requirements for portable clients or end-user devices. It is intended for devices that are used in high-assurance scenarios.

For changes to included SFRs, selections, and assignments required for this use case, see G.4 Portable Clients (laptops, tablets), Enhanced.

[USE CASE 5] CSfC EUD

Modified to address TRRT 1560 EUDs used in accordance with the CSfC Mobile Access Capability Package can include smart phones, tablets, and laptops. This use case covers the basic CSfC requirements for tablet and laptop EUDs (mobile devices are out of scope for this PP).

Although CSfC requires that users maintain physical control of EUDs at all times, this . This use case removes the assumption that the TOE is protected by the OE and adds requirements for audit and basic tamper detection and reportingfor protection of debug ports .

For changes to included SFRs, selections, and assignments required for this use case, see G.5 CSfC EUD.

[USE CASE 6] Tactical EUD

This use case adds requirements for portable end user computing devices in a tactical environment.

For changes to included SFRs, selections, and assignments required for this use case, see G.6 Tactical EUD.

[USE CASE 7] Enterprise Desktop clients

This use case covers the requirements for non-portable desktop computing devices in a low-threat enterprise physical environment.

This use case adds only audit to the base mandatory SFRs.

For changes to included SFRs, selections, and assignments required for this use case, see G.7 Enterprise Desktop clients.

[USE CASE 8] IoT Devices

IoT devices are field-located devices without human interfaces when in normal operation. In order to qualify for evaluation under this PP, the device must meet the basic criteria for a general-purpose platform, and not meet the requirements for a mobile device or network device.

For changes to included SFRs, selections, and assignments required for this use case, see G.8 IoT Devices.

1.5 Roles

1. Users (unprivileged users)
2. Administrators (privileged users)

2 Conformance Claims

Conformance Statement

A Security Target

An ST must claim exact conformance to this Protection Profile, as defined in the CC and CEM addenda for Exact Conformance, Selection-Based SFRs, and Optional SFRs (dated May 2017).

CC Conformance Claims

PP.

The evaluation methods used for evaluating the TOE are a combination of the workunits defined in [CEM] as well as the Evaluation Activities for ensuring that individual SFRs and SARs have a sufficient level of supporting evidence in the Security Target and guidance documentation and have been sufficiently tested by the laboratory as part of completing ATE_IND.1. Any functional packages this PP claims similarly contain their own Evaluation Activities that are used in this same manner.

CC Conformance Claims

This PP is conformant to Parts Part 2 (Extendedextended) and Part 3 (Extendedextended) of Common Criteria Version 3.1, Release 5 [CC] CC:2022, Revision 1.

PP Claim

This PP does not claim conformance to any other PPProtection Profile.

There are no PPs or PP-Modules that are allowed in a PP-Configuration with this PP.

Package Claim

• This PP is Functional Package for Secure Shell (SSH) Version 2.0 conformant.
• This PP is Functional Package for Transport Layer Security

(TLS), version 1.1 Conformant and Functional Package for Secure Shell (SSH), version 1.0 Conformant.

• Version 2.1 conformant.
• This PP is Functional Package for X.509 Version 1.0 conformant.
• This PP does not conform to any assurance packages.

The functional packages to which the PP conforms may include SFRs that are not mandatory to claim for the sake of conformance. An ST that claims one or more of these functional packages may include any non-mandatory SFRs that are appropriate to claim based on the capabilities of the TSF and on any triggers for their inclusion based inherently on the SFR selections made.

3 Security Problem Definition

• ensuring the integrity of its own firmware and hardware
• ensuring that it is resilient
• providing security services to tenant workloads

• Platform firmware and hardware
• Platform firmware updates
• Tenant initialization (boot)

3.1 Threats

T.PHYSICAL

An attacker with physical access might be able to compromise TOE integrity, subvert TOE protections, or access tenant data through hardware attacks such as probing, physical manipulation, fault-injection, side-channel analysis, environmental stress, or activating disabled features or pre-delivery services. This threat is addressed mitigated by TOE Objectives O.PHYSICAL_SECURITY and O.ATTACK_DETECTION_AND_RESPONSE functionality for the use cases listed below. For ; for other use cases, the expectation is that the environmental security objectives are sufficient mitigation for this threat is mitigated by Operational Environment Objective OE as mapped to Assumption A.PHYSICAL_PROTECTION. . PHYSICAL_PROTECTION

• Server-Class Platform, Enhanced
• Portable Clients (laptops, tablets), Enhanced
• CSfC EUD
• Tactical EUD
• IoT Devices

T.SIDE_CHANNEL_LEAKAGE

An attacker running in a tenant context might be able to leverage physical effects caused by the operation of the TOE to derive sensitive information about other tenants or the TOE.

T.PERSISTENCE

An attacker might be able to establish a permanent presence on the TOE in firmware. This could result in permanent compromise of tenant information, as well as TOE updates. This threat does not encompass attacker presence in tenant software, as tenant software is not part of the TOE.

T.UPDATE_COMPROMISE

An attacker may attempt to provide a compromised update of TOE firmware. Such updates can undermine the security functionality of the device if they are unauthorized, unauthenticated, or are improperly validated using non-secure or weak cryptography.

T.SECURITY_FUNCTIONALITY_FAILURE

An attacker could leverage failed or compromised security functionality to access, change, or modify tenant data, TOE data, or other security functionality of the device.

T.TENANT_BASED_ATTACK

An attacker running software as a tenant can attempt to access or modify TOE firmware or functionality. Note that direct tenant attacks against other tenants are not encompassed by this threat as they are out of scope.

T.NETWORK_BASED_ATTACK

An attacker from off the TOE can attempt to compromise the TOE through a network interface connected to an active TOE component, such as a management subsystem.

T.UNAUTHORIZED_RECONFIGURATION

An attacker might be able to modify the configuration of the TOE and alter its functionality. This might include, activating dormant subsystems, disabling hardware assists, or altering boot-time behaviors.

T.UNAUTHORIZED_PLATFORM_ADMINISTRATOR

An attacker might be able to attain platform administrator status by defeating or bypassing authentication measures.

3.2 Assumptions

A.PHYSICAL_PROTECTION

The TOE is assumed to be physically protected in its operational environment and thus is not subject to physical attacks that could compromise its security or its ability to support the security of tenant workloads. This assumption does not apply if the TOE implements any of the below, in which case physical protection from the Operational Environment is not assumed and the threat T.PHYSICAL and its associated TOE Objectives apply:

• Server-Class Platform, Enhanced
• Portable Clients (laptops, tablets), Enhanced
• CSfC EUD
• Tactical EUD
• IoT Devices

A.ROT_INTEGRITY

The TOE includes one or more Roots of Trust composed of TOE firmware, hardware, and pre-installed credentials. Roots of Trust are assumed to be free of malicious capabilities as their integrity cannot be verified.

A.TRUSTED_ADMIN

TOE Security Administrator are assumed to be trusted and to act in the best interest of security for the organization. The TOE is not expected to be capable of defending against a malicious Administrator that actively works to bypass or compromise the security of the platform.

A.MFR_ROT

The root signing credential of the manufacturer is assumed to be secure and has not been compromised.

A.TRUSTED_DEVELOPMENT_AND_BUILD_PROCESSES

The TOE cannot protect itself during its own development and build processes. Therefore it is assumed that the developers and participants in the build process are not hostile.

A.SUPPLY_CHAIN_SECURITY

The hardware components that comprise the TOE are assumed to be non-hostile and not compromised at the time of TOE construction. Likewise, the TOE is assumed to retain its integrity throughout transportation until delivery to its operational site.

A.CORRECT_INITIAL_CONFIGURATION

It is assumed that the initial setup and configuration of the TOE at its operational site is correct and in accordance with organizational security policy and operational use case.

A.TRUSTED_USERS

Physically present non-administrative users of the TOE are assumed to be trusted as far as they are assumed to not be actively trying to subvert the system. (Not for all use cases).

A.REGULAR_UPDATES

It is assumed that the manufacturer provides updates to TOE firmware in a timely manner in response to known vulnerabilities, and that Administrators apply these updates when they are received.

3.3 Organizational Security Policies

4 Security Objectives

4.1 Security Objectives for the

O.PHYSICAL_INTEGRITY

The TOE must be able to protect the physical platform and interfaces from access by physical means such as probing, physical manipulation, fault-injection, side-channel analysis, environmental stress, or activating disabled features or pre-delivery services. This includes specification of:

• Requirements for tamper detection
• Requirements for disabling or protection of external debug interfaces
• Requirements for updateability
• Requirements for environmental shielding

This Objective applies only if the TOE implements a use case that addresses the threat T.PHYSICAL.

O.ATTACK_DETECTION_AND_RESPONSE

The TOE must be capable of detecting attempts to compromise the physical or logical integrity of the TOE and respond by notifying a user or reporting the attempt to an enterprise security authority. This includes specification of:

• Requirements for responses to particular detected events. (resilience, secure state, etc.)
• Requirements for basic auditing capabilities and protection of audit records.
• Requirements for secure transmission of audit records (if applicable)

O.MITIGATE_FUNDAMENTAL_FLAWS

The TOE must have a capability for mitigating or fixing fundamental flaws through update or some other technical or operational means. This includes specifications of:

• Requirements for updateability of TOE firmware.

O.PROTECTED_FIRMWARE

TOE must ensure that its firmware cannot be modified other than through a non-bypassable trusted update process. This ensures the integrity of firmware both during the update process and while at rest. This includes specification of:

• Requirements for invocation of the trusted update process
• Requirements for non-bypassability of the update process
• Requirements for detection and reporting of attempts to modify TOE firmware outside of the trusted update process.

O.UPDATE_INTEGRITY

The TOE must ensure that updates to TOE firmware are authorized, authenticated, and properly validated prior to installation. This includes specification of:

• Requirements for protection of updates
• Requirements for authentication of update packages
• Requirements for management of updates
• Requirements for detection and reporting of update events, whether authorized or not.

O.STRONG_CRYPTOGRAPHY

Cryptography must meet the standards required for protection of National Security Systems data (in accordance with CNSSP 15, "Use of Public Standards for Secure Information Sharing"). This includes specification of:

• Requirements for use and configuration of cryptographic operations.
• Requirements for key generation
• Requirements for random bit generation support.

O.SECURITY_FUNCTIONALITY_INTEGRITY

The TOE should be able not be able to operate with failed or degraded security functionality in such a way as might compromise the security or integrity of the TOE or of TOE data.

• Requirements for detection of degraded or failed security functionality.
• Requirements for protection of platform credentials against compromise (secret keys, passwords, etc.)
• Requirements for secure destruction of platform credentials (if applicable)
• Requirements for quality of credentials (password lengths and the like)

O.TENANT_SECURITY

The TOE should provide capabilities and security services to tenant software to help tenants help themselves. This includes specification of:

• Requirements for providing cryptographic support to tenants (random bit generation, crypto support instructions).
• Requirements for support for separation of tenant workloads
• Requirements for supporting secure storage of tenant credentials
• Requirements for supporting secure boot of a tenant operating system

O.TRUSTED_CHANNELS

The TOE must protect certain network communications through guaranteed confidentiality, integrity, and authenticity. Such traffic includes communications with remote administrators, audit servers, update servers, and credential managers. This objective includes specification of:

• Requirements for the use of secure network protocols
• Requirements for the use of public key certificates
• Requirements for the authentication of endpoints

O.CONFIGURATION_INTEGRITY

The TOE should detect or prevent unauthorized users from being able to modify the system configuration. This includes:

• Requirements for authentication of Administrators before application of configuration modifications.
• Requirements for detection and reporting of attempts to modify the TOE configuration.

O.AUTHORIZED_ADMINISTRATOR

The TOE must ensure that Administrative actions can be taken only by authorized Administrators. This includes specification of:

• Requirements specifying actions allowable for the Administrator role
• Requirements for processes for authenticating Administrators
• Requirements for protection of Administrator credentials
• Requirements for setup and operation of a secure channel for remote administration
• Requirements for management of administrator sessions.

4.2 Security Objectives for the Operational Environment

OE.PHYSICAL_PROTECTION

Platforms that operate within data centers or in other access-controlled environments are expected to receive a considerable degree of protection from these environments. In addition to physical protection, these environments often provide malware-detection and behavior-monitoring services for networked computing assets.

OE.SUPPLY_CHAIN

The manufacturer is expected to implement processes to ensure that TOE hardware and firmware is not compromised between time of TOE manufacture and delivery to its operational site.

OE.TRUSTED_ADMIN

The administrator of the GPCP is not careless, willfully negligent or hostile, and administers the platform within compliance of enterprise security policy.

4.3 2 Security Objectives Rationale

5 Security Requirements

• Refinement operation (denoted by bold text or strikethrough text): is Is used to add details to a requirement (including replacing an assignment with a more restrictive selection) or to remove part of the requirement that is made irrelevant through the completion of another operation, and thus further restricts a requirement.
• Selection (denoted by italicized text): is Is used to select one or more options provided by the [CC] in stating a requirement.
• Assignment operation (denoted by italicized text): is Is used to assign a specific value to an unspecified parameter, such as the length of a password. Showing the value in square brackets indicates assignment.
• Iteration operation: is Is indicated by appending the SFR name with a slash and unique identifier suggesting the purpose of the operation, e.g. "/EXAMPLE1."

5.1 Security Functional Requirements

5.1.1 Auditable Events for Mandatory SFRs

5.1.2 Class: Security Management (FMT)

5.1.3 Class: Protection of the TSF (FPT)

5.1.4 TOE Security Functional Requirements Rationale

The following rationale provides justification for each security objective SFR for the TOE, showing that the SFRs are suitable to meet and achieve the security objectivesaddress the specified threats:
O_INTEGRITYSupports the objective through requiring that a TOE be either updateable or immutable2 (sel-based)Supports the objective through specifying an authenticated firmware update mechanismSupports the objective by indicating integrity failures in FPT_TUDFPT_TUD_EXT.2 FCS_SLT_Supports the objective by specifying the requirements for cryptographic salt generationFCS_HTTPS_EXT.1 Supports the objective by specifying requirements for the HTTPS protocolO.AUTHORIZED_ADMINISTRATORFIA_PMG

Table 4: SFR Rationale

ObjectiveThreat	Addressed by	Rationale
T.PHYSICAL		FPT_JTA_EXT.1	Supports the objective through Mitigates threat by restricting access to debug ports .
		FPT_TUD_EXT.1
		to authorized Administrators or physical presence.
		FPT_ROT_EXT.3 (objective)Supports the objective through requiring supply chain traceability	Mitigates threat by ensuring integrity of physical components and responding to integrity failures.
		FPT_JTA_EXT.2 (sel-based)	Supports the objective through requiring Mitigates threat by enforcing access control to debug ports to be disabled.
		FPT_PHP.1 (sel-based/objective)	Supports the objective through passive detection of Mitigates threat by passively detecting physical tampering.
FPT_PHP.2 (sel-based/objective)	Supports the objective through detection and reporting of Mitigates threat by providing methods to detect and report physical tampering.
FPT_PHP.3 (sel-based)	Supports the objective through resistance to Mitigates threat by resisting physical tampering.
T.SIDE_​CHANNEL_​LEAKAGE	FPT_TUD_EXT.
1	Mitigates threat by providing a means to eliminate side-channel flaws through updates.
T.PERSISTENCE	FPT_ROT_EXT.1	Mitigates threat by providing platform integrity to prevent intrusion of a persistent presence on the platform.
	FPT_TUDRVR_EXT.31 (sel-based)	Supports the objective through specifying a firmware update mechanism with delayed authentication.	FPT_TUDMitigates threat with firmware recovery mechanism in case of failure.
	FCS_STG_EXT.42 (sel-based)	Supports the objective through specifying a secure local firmware update mechanism.
O.ATTACK_DETECTION_AND_RESPONSE	FPT_ROT_EXT.2
	Mitigates threat by enforcing access control on key data to prevent its unauthorized disclosure.
	T.UPDATE_​COMPROMISE	FPT_PPF_EXT.1	Mitigates threat by using the official update process to be the only method to modify platform firmware.
		FPT_STMROT_EXT.1	Supports the objective by ensuring that audit events are marked with reliable time stamps.
		FAU_GEN.1 (sel-based)	Supports the objective by requiring reporting of security-related audit events.
		FAU_SAR.1 2	Mitigates threat by providing a means to attest the validity of updates.
		FCS_COP.1/Hash (sel-based)	Supports the objective by requiring that audit events be readable by an Administrator.	FAU_STG.1 Mitigates threat by providing a means to validate the integrity of an update using a hash.
		FCS_COP.1/SigVer (sel-based)	Supports the objective by requiring that audit records be protected from unauthorized deletion.
		FAU_STG.4 (sel-based)	Supports the objective by requiring that audit records be protected from automatic deletion.
FAU_STG_EXT.1 Mitigates threat by providing a means to validate the integrity of an update using a hash.
FPT_TUD_EXT.2 (sel-based)	Supports the objective by requiring that audit records be off-loaded to an external IT entityMitigates threat by using a digital signature mechanism to verify the integrity of updates and a rollback protection mechanism to prevent application of an unauthorized update.
FPT_PHPTUD_EXT.13 (sel-based)	Supports the objective through passive detection of physical tamperingMitigates threat by using the TOE's root of trust to validate the authenticity and integrity of an update when it is applied.
FPT_PHPTUD_EXT.34 (sel-based)	Supports the objective through resistance to physical tampering.
O.MITIGATE_FUNDAMENTAL_FLAWS
	Mitigates threat through an update mechanism that requires physical access to the TOE to use.
	T.SECURITY_​FUNCTIONALITY_​FAILURE	FCS_STG_EXT.1	Supports the objective through requiring that a TOE be either updateable or immutable.
		(optional)	Mitigates threat by generating keys/secrets and storing them in a secure manner, as well as destroying them on request.
FCS_CKM.6 (sel-based)		Supports the objective through specifying an authenticated firmware update mechanism.	FPT_TUD_EXT.3 Mitigates threat by using appropriate key destruction methods to protect the confidentiality of credential data.
FCS_COP.1/SigGen (sel-based)		Supports the objective through specifying a firmware update mechanism with delayed authentication.	FPT_TUD_EXT.4 Mitigates threat by generating digital signatures with strong encryption.
FCS_COP.1/SKC (sel-based)		Supports the objective through specifying a secure local firmware update mechanism.
O.PROTECTED_FIRMWARE		FPT_ROT_EXT.1	Supports the objective by ensuring that platform integrity is rooted in a trust anchor.
		FPT_PPF_EXT.1	Supports the objective by requiring that platform firmware be modifiable only through the update process.
		FPT_TUD_EXT.1	Supports the objective through requiring that a TOE be either updateable or immutable.
		FPT_ROT_EXT.2 Mitigates threat by establishing strong symmetric-key cryptography.
		FPT_FLS.1 (sel-based)	Mitigates threat by ensuring a DRBG self-test failure causes the TOE to enter an error state where it cannot perform secure functions using that DRBG.
		FDP_ITC_EXT.1 (sel-based)	Supports the objective by detecting integrity failures in platform firmware.	FPT_RVR_EXTMitigates threat by importing keys and credentials in a secure fashion.
		FCS_RBG.1 (sel-based)	Supports the objective by specifying a means for recovery from a boot firmware failure.	FPT_TUD_EXTMitigates threat by performing random-bit generation with sufficient complexity.
	FCS_RBG.2 (sel-based)	Supports the objective through specifying an authenticated firmware update mechanism.	FPT_TUD_EXTMitigates threat by using an external seed source to ensure sufficiently strong random-bit generation.
FCS_RBG.3 (sel-based)	Supports the objective through specifying a firmware update mechanism with delayed authentication.	FPT_TUD_EXTMitigates threat by using an internal seed source to ensure sufficiently strong random-bit generation.
FCS_RBG.4 (sel-based)	Supports the objective through specifying a secure local firmware update mechanism.
O.UPDATE_INTEGRITY	FPT_PPF_EXT.1	Supports the objective by requiring that platform firmware be modifiable only through the update process.
	FPT_ROT_EXT.2	Supports the objective by validating the integrity of platform firmware prior to execution.
	FPT_TUD_EXT.1	Supports the objective through requiring that a TOE be either updateable or immutable.
	FPT_TUD_EXT.2 (sel-based)	Supports the objective through specifying an authenticated firmware update mechanism.
	FPT_TUD_EXT.3 (sel-based)	Supports the objective through specifying a firmware update mechanism with delayed authentication.
	FPT_TUD_EXT.4 (sel-based)	Supports the objective through specifying a secure local firmware update mechanism.
O.STRONG_CRYPTOGRAPHY
	Mitigates threat by using multiple internal seed sources to ensure sufficiently strong random-bit generation.
	FCS_RBG.5 (sel-based)	Mitigates threat by ensuring that each noise source's random data is combined to ensure strong entropy when multiple sources are used.
	FPT_TST.1 (sel-based)	Mitigates threat by using self-tests to ensure correct operation of the DRBG.
	T.TENANT_​BASED_​ATTACK	FPT_STM.1	Mitigates threat by ensuring that audit data indicating a potential attack is accurately timestamped.
		FCS_RBG.6 (optional)	Mitigates threat by providing a well-defined interface by which tenant software can access the TSF to obtain random data.
		FCS_SLT_EXT.1 (optional)	Mitigates threat by using salts to increase the effectiveness of cryptographic functions used to protect against attack.
		FDP_TEE_EXT.1 (optional)
		Mitigates threat by establishing a trusted execution environment for tenant software to use.
		FCS_CKM.1/AKAKG (sel-based/optional)	Supports the objective by specifying the requirements for generating asymmetric keysMitigates threat by generating strong cryptographic asymmetric keys to protect stored data.
		FCS_CKM.1/SKSKG (sel-based/optional)	Supports the objective by specifying the requirements for generating symmetric keysMitigates threat by generating strong cryptographic symmetric keys to protect stored data.
		FCS_CKM.26 (sel-based/optional)	Supports the objective by specifying the requirements for cryptographic key establishmentMitigates threat by implementing key destruction to prevent the disclosure of keys used to protect stored data.
FCS_CKM_EXT.5 (sel-based/optional)		Supports the objective by specifying the requirements for cryptographic key derivationMitigates threat by utilizing strong algorithms to derive keys that protect stored data.
FCS_COP.1/Hash (sel-based/optional)		Supports the objective by specifying the requirements for cryptographic hashingMitigates threat by implementing hash functions used for trusted communications.
FCS_COP.1/KATKeyedHash (sel-based/optional)		Supports the objective by specifying the requirements for key agreement and transportMitigates threat by implementing MAC functions used for trusted communications.
FCS_COP.1/KeyedHashSigGen (sel-based/optional)		Supports the objective by specifying the requirements for keyed hashesMitigates threat by implementing signature generation functions used for protected storage.
FCS_COP.1/SigGenSigVer (sel-based/optional)		Supports the objective by specifying the requirements for digital signature generationMitigates threat by implementing signature verification functions used for protected storage.
FCS_COP.1/SigVerSKC (sel-based/optional)		Supports the objective by specifying the requirements for digital signature verification.	FCS_COP.1/SKC Mitigates threat by implementing symmetric encryption functions used for protected storage.
FAU_GEN.1 (sel-based/optional)		Supports the objective by specifying the requirements for symmetric-key cryptography.	FCS_RBG_EXTMitigates threat by generating audit records that could provide evidence of attack or misuse.
FAU_SAR.1 (sel-based/optional)		Supports the objective by specifying the requirements for random-bit generation services.
O.SECURITY_FUNCTIONALITY_INTEGRITY		FPT_PPF_EXT.1	Supports the objective by requiring that platform firmware be modifiable only through the update process.
		FCS_STG_EXT.1 (optional)	Supports the objective by specifying the types of credential storage supported by the TOE.
		FCS_CKM.4 Mitigates threat by recording audit data in a manner that could be interpreted to discover evidence of attack.
		FAU_STG.1 (sel-based)	Mitigates threat by using an external server to preserve audit data that may provide evidence of an attack.
	FAU_STG.2 (sel-based)	Mitigates threat by preventing audit records indicating a potential attack from being destroyed.
	FAU_STG.5 (sel-based)	Supports the objective by specifying the requirements for credential and key destructionMitigates threat by ensuring that exhaustion of audit storage does not prevent audit data indicating a potential attack from being generated.
	FCS_CKMSTG_EXT.42 (sel-based)	Supports the objective by specifying the timing for credential and key destructionMitigates threat by using cryptography to protect the confidentiality of key data from outside access.
FCS_STG_EXT.23 (sel-based)	Supports the objective by specifying the types of material that must be encrypted for storageMitigates threat by using cryptography to protect the integrity of key data from outside modification.
T.NETWORK_​BASED_​ATTACK	FPT_STM.1	Mitigates threat by ensuring that audit data indicating a potential attack is accurately timestamped.
	FCS_STGSLT_EXT.3 (1 (optional)	Mitigates threat by using salts to increase the effectiveness of cryptographic functions used to protect against attack.
	FCS_CKM.1/AKG (sel-based)	Supports the objective by specifying the encryption requirements for credential storage.	FDP_ITC_EXT.1 Mitigates threat by generating strong cryptographic asymmetric keys to protect data in transit.
	FCS_CKM.1/SKG (sel-based)	Supports the objective by specifying the requirements for import of keys and credentials.
	O.TENANT_SECURITY	FCS_ENT_EXT.1 (optional)	Supports the objective by requiring that the TOE provide entropy to tenant software.
		FCS_STG_EXT.1 (optional)	Supports the objective by specifying the types of credential storage supported by the TOE.
		FDP_TEE_EXT.1 (optional)	Supports the objective by specifying the requirements for a trusted execution environment.
		FCS_STG_EXT.2 Mitigates threat by generating strong cryptographic symmetric keys to protect data in transit.
		FCS_CKM.2 (sel-based)	Mitigates threat by implementing key establishment to negotiate trusted channels to protect data in transit.
		FCS_CKM.6 (sel-based)	Mitigates threat by implementing key destruction to prevent the compromise of trusted channels.
	FCS_COP.1/Hash (sel-based)	Mitigates threat by implementing hash functions used for trusted communications.
	FCS_COP.1/KAT (sel-based)	Supports the objective by specifying the types of material that must be encrypted for storageMitigates threat by implementing key agreement and transport functions used for trusted communications.
	FCS_STG_EXT.3COP.1/KeyedHash (sel-based)	Supports the objective by specifying the encryption requirements for credential storage.	FDP_ITC_EXT.1 Mitigates threat by implementing MAC functions used for trusted communications.
	FCS_COP.1/SigGen (sel-based)	Supports the objective by specifying the requirements for import of keys and credentials.
	O.TRUSTED_CHANNELS
		Mitigates threat by implementing signature generation functions used for trusted communications.
		FCS_COP.1/SigVer (sel-based)
		Mitigates threat by implementing signature verification functions used for trusted communications.
		FCS_IPSEC_EXTCOP.1/SKC (sel-based)	Supports the objective by specifying requirements for the IPSec protocol.	FIA_X509_Mitigates threat by implementing symmetric encryption functions used for trusted communications.
		FAU_GEN.1 (sel-based)	Mitigates threat by generating audit records that could provide evidence of attack or misuse.
		FCS_HTTPS_EXT.1 (sel-based)	Supports the objective by specifying how X.509 certificate validation is performed.	FIA_X509_EXT.2 Mitigates threat by implementing HTTPS as a means to protect data in transit.
		FCS_IPSEC_EXT.1 (sel-based)	Supports the objective by specifying how X.509 certificate authentication is performed.Mitigates threat by implementing IPsec as a means to protect data in transit.
	FTP_ITC_EXT.1 (sel-based)	Supports the objective by specifying allowable trusted channel Mitigates threat by ensuring that sensitive data in transit uses trusted protocols.
FTP_ITE_EXT.1 (sel-based)	Supports the objective by specifying requirements for moving data through untrusted channelsMitigates threat by ensuring that sensitive data transmitted over untrusted channels is encrypted prior to transit.
FTP_ITP_EXT.1 (sel-based)	Supports the objective by allowing physically protected communications channels.	FTP_TRPMitigates threat by using a physically protected channel to protect data in transit.
FAU_SAR.1 (sel-based)	Supports the objective by specifying allowable uses for trusted channels.
O.CONFIGURATION_INTEGRITY	FMT_CFG_EXT.1	Supports the objective by requiring that default Administrator credentials be changed.
	FIA_UIA_EXTMitigates threat by recording audit data in a manner that could be interpreted to discover evidence of attack.
	FAU_STG.1 (sel-based)	Supports the objective by requiring Administrators be authenticated before making changes.	FMT_MOF_EXT.1 Mitigates threat by using an external server to preserve audit data that may provide evidence of an attack.
	FAU_STG.2 (sel-based)	Supports the objective by specifying that management functions be performed by Administrators.	FMT_SMF.1 Mitigates threat by preventing audit records indicating a potential attack from being destroyed.
	FAU_STG.5 (sel-based)	Supports the objective by specifying the management functions implemented by the TOE.	FMT_SMRMitigates threat by ensuring that exhaustion of audit storage does not prevent audit data indicating a potential attack from being generated.
FTP_TRP.1 (sel-based)	Supports the objective by defining the roles of Administrator and User.
Mitigates threat by ensuring that remote administration only uses trusted channels.
T.UNAUTHORIZED_​RECONFIGURATION	FMT_CFG_EXT.1	Supports the objective by requiring that default Administrator credentials be changed.
	FIA_TRT_EXT.1 (optional)	Supports the objective by limiting the number of automated authentication attempts.
	FIA_AFL_EXT.1 (sel-based)	Supports the objective by requiring that Administrators be authenticated.
	Mitigates threat by preventing knowledge of a default credential from being used to access the TSF without authorization.
	FMT_MOF.1	Mitigates threat by permitting management functions to be used only by authorized users.
FMT_SMF.1	Mitigates threat by specifying the management functions implemented by the TSF.
FMT_SMR.1	Mitigates threat by defining the management roles which can be used to grant access to management functions.
FIA_UIA_EXT.1 (sel-based)	Supports the objective by specifying password complexity requirements.
FIA_UAU.5 (sel-based)	Supports the objective by specifying supported authentication mechanisms.
FIA_UAU.7 (sel-based)	Supports the objective by requiring that authentication factor feedback be suppressed.
FIA_UIAMitigates threat by preventing the TSF from being modified by an unauthenticated subject.
T.UNAUTHORIZED_​PLATFORM_​ADMINISTRATOR	FPT_STM.1	Mitigates threat by ensuring that time-based authentication throttling or lockout is accurately enforced.
	FIA_TRT_EXT.1 (sel-basedoptional)	Supports the objective by requiring Administrators be authenticated before making changesMitigates threat by throttling authentication to prevent access via brute force.
	FIA_X509AFL_EXT.1 (sel-based)	Supports the objective by specifying how X.509 certificate validation is performed.Mitigates threat by limiting further authentication attempts once a failure threshold of a critical authentication mechanism has been reached.
	FIA_X509PMG_EXT.2 (sel-based)	Supports the objective by specifying how X.509 certificate authentication is performed.	FMT_MOF_EXT.1 (sel-based)	Supports the objective by specifying that management functions be performed by Administrators.	FMT_SMF.1 Mitigates threat by enforcing password complexity requirements to prevent credentials from being easily guessed.
	FIA_UAU.5 (sel-based)	Supports the objective by specifying the management functions implemented by the TOE.	FMT_SMR.1 Mitigates threat by implementing multiple authentication mechanisms for accessing the TSF.
	FIA_UAU.7 (sel-based)	Supports the objective by defining the roles of Administrator and UserMitigates threat by preventing disclosure of authentication data during authentication attempts.

5.2 Security Assurance Requirements

5.2.1 Class ASE: Security Target

5.2.2 Class ADV: Development

5.2.3 Class AGD: Guidance Documentation

5.2.4 Class ALC: Life-cycle Support

5.2.5 Class ATE: Tests

5.2.6 Class AVA: Vulnerability Assessment

Appendix A - Optional Requirements

A.1 Strictly Optional Requirements

A.1.1 Auditable Events for Strictly Optional Requirements

A.1.2 Class ALC: Life-cycle Support

A.1.3 Class: Cryptographic Support (FCS)